Im Moment ist es so implementiert, dass erwartet wird, dass Code-Verifier oder CSRF-Token als solche an den Browser gehen: Im Request an den Redirekt-Endpunkt müssen sie aus dem Request ermittelbar sein (z.B. im Cookie). Dafür gibt es die Konfigurations-Attribute code_verifier_value und csrf_token_value:

oauth2 "my-ac" {
  ...
  code_verifier_value = request.cookies.cv
#  csrf_token_value = request.cookies.ct
  ...
}

Ohne einen zentralen Store ist es dann auch wahrscheinlich, dass Access-/Id-/Refresh-Tokens als solche (als Cookie) im Browser gespeichert werden. Hätte man einen (von verschiedenen Couper-Instanzen verwendeten) zentralen Store, könnte man die Tokens selbst im Store speichern und nur eine Referenz darauf an den Browser gehen. Das würde ggfs. die Sicherheit noch erhöhen.
Ebenso könnten dann Code-Verifier/CSRF-Token selbst im Store verbleiben und nur Referenzen darauf an den Browser gehen.
Verbaut man sich nun durch die genannten Konfigurations-Attribute eine mögliche Erweiterung durch einen zentralen Store? Vermutlich nicht: code_verifier_value/csrf_token_value müssten dann nur anders interpretiert werden, nämlich als Referenzen auf die eigentlichen Werte. Welche Variante gewünscht ist, ließe sich sicherlich konfigurativ ausdrücken.

Verbaut man sich nun durch die genannten Konfigurations-Attribute eine mögliche Erweiterung durch einen zentralen Store? Vermutlich nicht: code_verifier_value/csrf_token_value müssten dann nur anders interpretiert werden, nämlich als Referenzen auf die eigentlichen Werte. Welche Variante gewünscht ist, ließe sich sicherlich konfigurativ ausdrücken.

The current idea is, that code_verifier_value is defined as an arbitrary expression that usually involves cookies. if we would incorporate a KV interface, we could provide a lookup function as a simple solution. That would still fit the expression approach.

But I would rather make that token store a built-in feature that is configured outside of the AC. We could then reference it with a new set of config attributes that are mutually exclusive with code_verifier_value.

For the task here, I agree that we can proceed with the value-approach.